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EXECUTIVE  SUMMARY 


The  Automatic  Identification  System  (AIS)  is  an  autonomous  and  continuous  broadcast  system  that 
exchanges  maritime  safety/security  information  between  participating  vessels  and  shore  stations.  In  addition 
to  providing  a  means  for  maritime  administrations  to  effectively  track  the  movement  of  vessels  in  coastal 
and  inland  waters,  AIS  can  be  a  means  to  transmit  information  to  ships  in  port  or  underway  that  contributes 
to  safety-of-navigation  and  protection  of  the  environment. 

Since  2007,  the  United  States  Coast  Guard  Research  and  Development  Center  (RDC)  has  been  working  on 
an  AIS  Transmit  Project  to  determine  what  additional  information  is  required  by  AIS  users,  recommend 
how  the  information  should  be  transmitted,  and  test  the  transmission  of  this  information  at  test  bed  sites. 

This  information  is  transmitted  using  AIS  Application  Specific  Messages  (ASMs).  Several  standard  ASMs 
have  been  defined  and  prototype  methods  have  been  developed  for  message  creation,  routing,  queuing, 
transmission  and  monitoring. 

This  report  describes  the  AIS  system  architecture  developed  by  RDC  that  is  in  alignment  with  International 
Standards,  and  meets  the  need  for  a  cohesive,  flexible,  and  robust  system  for  the  transmission  of  electronic 
Maritime  Safety  Information  (eMSI).  Two  key  components  of  the  AIS  Transmit  architecture  are  the  AIS 
Router  and  ASM  Manager,  which  are  discussed  in  detail. 

The  primary  component  that  implements  the  AIS-Logical  Shore  Station  (LSS)  is  an  “AIS  Router;”  so  called, 
because  it  is  responsible  for  routing  the  AIS  data  between  the  AIS  service  clients  and  the  AlS-Physical 
Shore  Station  (PSS).  A  market  survey  conducted  by  RDC  identified  four  major  commercial  vendors  that 
supply  AIS  Routers  as  part  of  their  AIS  shoreside  network  software:  Kongsberg  C-Scope,  Gatehouse  AIS, 
Transas  AIS  Network,  and  CNS  DataSwitch.  RDC  conducted  testing  of  the  four  AIS  routers  to  determine 
data  throughput  and  client  connection  capacity.  The  test  results  show  that  any  of  the  four  commercial 
systems  would  be  suitable  for  the  current  USCG  traffic  conditions. 

The  ASM  Manager  is  software  that  adds  the  required  queuing  and  prioritization  algorithms  to  the  AIS 
router.  This  is  not  commercially  available,  so  software  was  developed  to  layer  this  functionality  on  top  of  an 
AIS  router.  The  ASM  Manager  performs  the  following  tasks. 

1 .  Ensures  ASM  messages  are  valid  before  transmission. 

2.  Monitors  Very  High  Frequency  (VHF)  Data  Link  (VDL)  and  ASM  demand  and  adjusts  the  transmit 
rate  so  as  to  not  overload  the  VDL. 

3.  Allows  for  user-specified  priorities  along  with  prioritization  based  upon  message  type  and  content. 

4.  Determines  if  a  message  should  be  transmitted  from  a  given  transmitter  based  upon  location. 

5.  Ensures  messages  are  transmitted. 

6.  Keeps  messages  in  queue  until  acknowledgement  is  received  from  the  Base  Station. 

7.  Allows  for  acknowledgements  to  be  routed  back  to  user. 

8.  Manages  the  repetition  of  messages  that  need  to  be  retransmitted  on  a  periodic  basis. 

The  results  of  base  station  testing  and  how  the  results  impact  the  transmit  architecture  are  also  presented. 
There  are  two  methods  for  delivering  the  information  to  an  AIS  base  station  so  that  it  can  transmit  an  AIS 
message:  using  a  National  Maritime  Electronic  Association  (NMEA)  Broadcast  Binary  Message  (BBM)  (or 
Addressed  Binary  Message  (ABM))  sentence  and  by  using  a  VHF  Datalink  Message  (VDM)  sentence.  In 
addition,  there  are  two  main  channel  access  modes  that  a  base  station  can  use:  Fixed  Access  Time  Division 
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Multiple  Access  (FATDMA)  and  Random  Access  Time  Division  Multiple  Access  (RATDMA).  Each  of 
these  modes  was  tested  using  two  different  AIS  base  stations  and  some  differences  were  observed  in 
performance.  Since  the  USCG  uses  the  L-3  Protec  base  station,  the  architecture  needs  to  be  based  on  the  L-3 
performance.  Either  VDM  or  BBM/ABM  sentences  can  be  used.  Since  the  L-3  only  uses  a  1 -minute  interval 
for  BBM  sentence  transmission  a  1 -minute  interval  on  the  ASM  Manager  queue  works  well.  Using 
FATDMA  mode  only  is  the  most  efficient,  since  if  RATDMA  mode  is  needed  then  there  needs  to  be 
sufficient  reserved  slots  in  each  4-second  window  to  handle  the  ASM  manager  traffic  (meaning  about  15 
times  as  many  slots  reserved). 

Additionally,  the  report  presents  a  mapping  of  AIS  transmit  message  types  onto  the  recommended  transmit 
methodology  based  upon  the  results  of  RDC  testing.  There  are  three  ways  to  have  a  base  station  transmit  an 
AIS  message;  each  method  has  pros  and  cons,  and  some  AIS  messages  are  better  suited  to  certain  methods. 
The  recommended  types  of  messages  are  listed  under  the  three  methods  of  transmission. 


1.  Base  Station  Programming 

•  AIS  Message  4  -  base  station  report 

•  AIS  Message  17  -  Differential  Global  Navigation  Satellite  System  (DGNSS)  corrections  broadcast 

•  AIS  Message  20  -  data  link  management 

•  AIS  Message  24  -  extended  base  station  information  (if  supported  by  the  base  station) 

•  AIS  Message  22  -  channel  management  (if  using  Area-based  channel  management) 

•  AIS  Message  21  -  AtoN  (if  only  a  few  virtual  or  synthetic  aids,  with  static  parameters) 

2.  NMEA  Message  Programming 

•  AIS  Message  6  -  addressed  binary  message 

•  AIS  Message  8  -  broadcast  binary  message 

•  AIS  Message  12  -  addressed  safety-related  text 

•  AIS  Message  14  -  broadcast  safety-related  text 

•  AIS  Message  25  -  short  unscheduled  binary  transmission 

•  AIS  Message  26  -  scheduled  binary  transmission 

•  AIS  Message  22  -  channel  management  (if  used  for  specific  station  channel  management) 

•  AIS  Message  10  -  request  Universal  Time  Coordinated  (UTC)  date/time  (this  is  not  supported  under 
the  current  L-3  firmware  but  will  be  in  the  next  revision) 

•  AIS  Message  1 5  -  request  for  specific  message(s)  (base  station  will  generate  an  ABK  for  this  so 
gives  additional  status) 

•  AIS  Message  16  -  assignment  mode  (especially  if  assigning  slots  that  then  need  to  be  reserved) 

•  AIS  Message  21  -  AtoN  (for  virtual  or  synthetic  aids,  with  parameters  that  need  to  be  changed  by 

the  client  application  periodically  -  perhaps  due  to  monitoring) 

3.  Directly  Created  AIS  Messages 

•  AIS  Message  16  -  assignment  mode  (for  assigned  rate  mode  only) 

•  AIS  Message  21  -  AtoN  (for  virtual  or  synthetic  aids,  if  too  many  for  the  base  station  to  manage 

using  other  methods) 

•  AIS  Message  24  -  extended  base  station  information  (if  base  station  does  not  support  sending  the 
message  automatically  -  this  is  the  case  with  the  L-3  Protec) 


The  AIS  transmit  architecture  also  require  integration  into  the  Vessel  Traffic  Service’s  (VTS’s)  operational 
system  (Ports  and  Waterways  Safety  System  (PAWSS)  and  the  Nationwide  Automatic  Identification  System 
(NAIS)  architectures.  This  report  discusses  the  key  architecture  features  for  integration  into  these  USCG 
systems. 
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Transition  strategies  are  presented  to  migrate  the  RDC  AIS  Transmit  capabilities  into  operational  AIS 
systems  at  the  three  test  bed  sites  -  Tampa  Bay,  FL;  Stellwagen  Bank,  MA;  and  Columbia  River,  WA;  and 
the  future  Vessel  Traffic  Service  systems  being  developed  under  PAWSS. 

Interfacing  the  AIS  Transmit  architecture  with  agencies  that  provide  maritime  safety  and  security 
information  for  ASMs  is  also  discussed.  A  transmit  architecture  is  proposed  to  interface  with  various 
agencies  to  access  required  information.  Two  examples  discussed  are  the  NOAA  National  Marine  Sanctuary 
(NMS)  and  the  United  States  Army  Corps  of  Engineers  (US  ACE).  The  NMS  provides  a  variety  of  important 
marine  protection  information  to  the  mariner  such  as  Seasonal  Management  Areas,  Right  Whale  Listening 
Buoys,  Dynamic  Management  Areas,  areas  to  be  avoided,  Mandatory  Ship  Reporting  Areas,  and 
recommended  routes.  NOAA's  National  Ocean  Service  (NOS)  provides  accurate  real-time  information  such 
as  water  levels,  currents,  and  other  oceanographic  and  meteorological  data.  The  USACE  provide  river  lock 
information  and  river  level  and  current  data  on  the  Inland  Waterways. 
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1  BACKGROUND 


The  Automatic  Identification  System  (AIS)  is  an  autonomous  and  continuous  broadcast  system  that 
exchanges  maritime  safety/security  information  between  participating  vessels  and  shore  stations.  In  addition 
to  providing  a  means  for  maritime  administrations  to  effectively  track  the  movement  of  vessels  in  coastal 
and  inland  waters,  AIS  can  be  a  means  to  transmit  information  from  shore  to  ships  in  port  or  underway  that 
contributes  to  safety-of-navigation  and  protection  of  the  environment. 

In  the  United  States,  it  is  intended  that  this  additional  information  be  transmitted  from  shore-side  AIS  base 
stations  in  a  binary  message  format  as  part  of  an  e-Navigation  strategy.  e-Navigation  is  defined  in  the 
Committee  on  the  Marine  Transportation  System  (CMTS)  e-Navigation  Strategy  Action  Plan  [1]  as: 

“e-Navigation  is  the  harmonised  collection,  integration,  exchange,  presentation  and  analysis  of 
maritime  information  onboard  and  ashore  by  electronic  means  to  enhance  berth  to  berth  navigation 
and  related  services,  for  safety  and  security  at  sea  and  protection  of  the  marine  environment  ” 

To  implement  the  e-Navigation  strategy  into  AIS,  the  United  States  Coast  Guard  (USCG)  Research  and 
Development  Center  (RDC)  has  been  working  on  an  AIS  Transmit  Project  since  2007  to  research  what 
additional  information  is  required  by  AIS  users,  to  recommend  how  the  information  is  transmitted,  and  test 
the  transmission  of  this  information  at  test  bed  sites.  As  part  of  the  AIS  Transmit  Project,  the  RDC  has 
developed  processes  to  manage  this  information.  This  information  is  called  AIS  Application  Specific 
Messages  (ASMs).  Several  standard  ASMs  have  been  defined  and  prototype  methods  have  been  developed 
for  message  creation,  routing,  queuing,  transmission  and  monitoring.  Appendix  A  discusses  the  background 
of  the  AIS  Transmit  Project. 

In  general,  ASMs  are  either  created  by  Vessel  Traffic  Service  (VTS)  operators,  Sector  Command  Center 
(SCCs)  operators,  or  retrieved  from  an  information  data  source,  such  as  the  National  Oceanographic  and 
Atmospheric  Administration’s  (NOAA)  Physical  Oceanographic  Real  Time  System  (PORTS)  or  United 
States  Army  Corp  of  Engineers  (US  ACE)  databases.  This  information  is  then  formatted  into  ASMs  based 
upon  accepted  standards.  Once  formatted,  messages  are  prioritized,  geographically  identified,  and  queued. 
As  part  of  the  queuing  process,  the  Very  High  Frequency  (VHF)  Data  Link  (VDL)  needs  to  be  monitored 
and  feedback  provided  to  the  queuing  process  to  adjust  message  output.  Once  formatted,  the  ASMs  are  sent 
to  the  AIS  base  station  or  AIS  Aid  to  Navigation  (AtoN)  unit  for  transmission. 

In  order  to  have  a  cohesive,  flexible  and  robust  AIS  transmit  system  that  meets  all  user’s  requirements,  an 
AIS  transmit  architecture  needs  to  be  fully  defined.  This  report  proposes  such  an  architecture  and  describes 
the  various  components  of  that  architecture  including  an  ASM  Manager  to  implement  the  queuing  and 
prioritization  algorithms.  These  processes  also  require  integration  into  the  VTS’s  operational  system,  Ports 
and  Waterways  Safety  System  (PAWSS),  and  the  Nationwide  Automatic  Identification  System  (NAIS) 
architectures.  This  report  discusses  the  key  architecture  features  for  integration  into  these  CG  systems. 
Results  of  base  station  testing  and  how  the  results  impact  the  transmit  architecture  are  also  presented. 
Additionally,  the  report  presents  a  mapping  of  AIS  transmit  message  types  onto  the  recommended  transmit 
methodology  based  upon  the  results  of  RDC  testing. 

2  AIS  TRANSMIT  ARCHITECTURE 

RDC  has  developed  a  proposed  AIS  architecture  that  is  in  alignment  with  International  Standards.  This  is 
described  in  the  sections  below  after  first  detailing  the  International  Association  of  Marine  Aids  to 
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Navigation  and  Lighthouse  Authorities  (IALA)  and  International  Maritime  Organization  (IMO)  reference 
architecture  for  e-Navigation. 


2.1  TALA  Reference  Architecture 

The  1998  IMO  Performance  Standards  for  AIS  [2]  state: 

1.2  The  AIS  should  improve  the  safety  of  navigation  by  assisting  in  the  efficient  navigation  of 
ships,  protection  of  the  environment,  and  operation  of  Vessel  Traffic  Services  (VTS),  by  satisfying 
the  following  functional  requirements: 

.1  in  a  ship-to-ship  mode  for  collision  avoidance; 

.2  as  a  means  for  littoral  States  to  obtain  information  about  a  ship  and  its  cargo;  and 

.3  as  a  VTS  tool,  i.e.  ship-to-shore  (traffic  management) 

This  was  expanded  upon  by  the  International  Telecommunication  Union  Radiocommunications  Sector 
(ITU-R)  in  the  preamble  to  Recommendation  M.1371  [3]: 

The  ITU  Radiocommunication  Assembly  considering  (...) 

b)  that  the  use  of  a  universal  shipborne  AIS  allows  efficient  exchange  of  navigational  data 
between  ships  and  between  ships  and  shore  stations,  thereby  improving  safety  of  navigation; 
d)  that  although  this  system  is  intended  to  be  used  primarily  for  surveillance  and  safety  of 
navigation  purposes  in  ship  to  ship  use,  ship  reporting  and  vessel  traffic  services  (VTS) 
applications,  it  may  also  be  used  for  other  maritime  safety  related  communications,  provided 
that  the  primary  functions  are  not  impaired; 

f  that  this  system  is  capable  of  expansion  to  accommodate  future  expansion  in  the  number  of 
users  and  diversification  of  applications,  including  vessels  which  are  not  subject  to  IMO  AIS 
carriage  requirements,  aids  to  navigation  and  search  and  rescue; 

And  further  noted  in  IALA  Recommendation  A- 123,  on  “The  Provision  of  Shore  Based  Automatic 
Identification  System  (AIS),”[4]  which  states  “National  Members  and  other  appropriate  authorities  should 
therefore  consider  the  provision  of  an  AIS  shore  infrastructure  so  that  the  full  benefit  of  the  system  can  be 
realized  in  terms  of  navigation  safety  and  protection  of  the  environment.” 

IALA  Recommendation  A- 124,  “On  The  AIS  Service”  [5]  provides  a  service  model  for  the  AlS-based  shore 
service  component  of  e-Navigation.  The  details  are  described  in  the  various  Appendices  to  A-124.  Figure  1 
shows  the  layered  structure  for  this  service.  The  three  main  functional  layers  are  the  Service  Management 
Layer  (AIS  Service  Management  Layer  or  AIS-SM),  the  Logical  Layer  (AIS  Logical  Shore  Station  or  AIS- 
LSS),  and  the  Physical  Layer  (AIS  Physical  Shore  Stations  or  AIS-PSS).  Each  layer  is  comprised  of  “the 
service  component  itself,  which  provides  the  required  functionality  in  terms  of  AIS  specific  data  processing; 
the  supporting  components  and  resources,  which  are  exclusively  used  by  the  AIS  Service,  such  as 
computers  and  local  networking  devices,  i.e.  the  so  called  service-owned  infrastructure;  and  the  Human 
Machine  Interfaces  (HMI)  to  allow  for  (remote)  access  to  Technical  Operation  Personnel.” 

The  AlS-Service  Manager  (SM)  (described  in  more  detail  in  Appendix  1 1  [6]  provides  for  the  management 
of  the  entire  AIS  service.  This  includes  configuration  and  monitoring  of  all  components  and  an  HMI  for 
technical  personnel  to  do  the  configuration  and  monitoring. 


The  AIS-Logical  Shore  Station  (LSS)  (described  in  more  detail  in  Appendix  9  [6]  acts  as  a  software  router 
for  AIS  data  going  to  and  from  the  clients  and  the  AIS  PSS  Controlling  Units  (AIS-PCU).  It  is  responsible 
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for  the  management  of  client  and  AIS-PSS  connections,  filtering  of  data  on  either  or  both  connections,  and 
data  logging. 

The  AlS-Physical  Shore  Station  (PSS)  (described  in  more  detail  in  Appendix  10  [6]  “is  an  abstract  concept 
that  encompasses  multiple  real  physical  elements  of  a  shore-based  AIS  Service.”  The  major  components  of 
an  AIS-PSS  are:  an  AIS-PCU  that  is  in  charge  of  controlling  one  or  more  AIS  fixed  stations;  at  least  one 
AIS  fixed  station  (base  station,  limited  base  station,  AtoN,  or  repeater  station)  that  provides  the  interface  to 
the  VDL;  and  an  agent  of  the  AIS-SM  to  allow  for  configuration  and  monitoring  of  the  AIS-PCU  and  AIS 
fixed  station(s).  In  some  cases  all  of  this  functionality  can  be  rolled  into  one  physical  component. 
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Figure  1.  Layered  structure  of  AIS  service. 
(Structure  model  of  the  AIS  Service,  Figure  4  from  [5]) 
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2.2  Proposed  Transmit  Architecture 

One  of  the  major  outcomes  of  the  test  bed  was  the  identification  and  quantification  of  the  processes  needed 
in  order  to  create  and  transmit  ASMs:  Message  Creation,  Routing,  Transmission,  and  VDL  Monitoring.  This 
is  shown  in  Figure  2.  Message  creation  could  be  accomplished  automatically  from  a  database  or  user- 
created.  If  the  message  created  is  from  a  database,  then  software  is  needed  to  fetch  the  data  and  put  into  the 
correct  format  (AIS  ASM  embedded  into  a  National  Maritime  Electronic  Association  (NMEA)  sentence).  If 
user-created,  then  software  tools  (preferably  GUI-based)  are  needed  to  put  the  desired  information  into  the 
ASM.  Message  routing  involves  both  the  queue  process  and  rules-based  prioritization.  This  is  not  available 
off-the-shelf  currently  so  additional  software  is  needed  to  accomplish  this.  Message  transmission  involves 
routing  the  message  to  the  correct  transmitter  according  to  area  (auto  or  user-specified).  Monitoring  is  VDL 
loading  monitoring  to  ensure  that  the  number  of  messages  desired  to  be  transmitted  do  not  overload  the 
VDL. 


Figure  2.  AIS  transmit  and  NAIS  integration  architecture. 


The  identification  of  these  processes  led  to  the  development  of  a  prototype  AIS  Transmit  architecture,  which 
includes  the  use  of  an  ASM  Manager  and  an  AIS  network  controller  or  “AIS  router”  that  routes  data 
between  the  Physical  Shore  Stations  (PSSs)/AIS  Base  Stations  (BSs)  and  the  various  clients  (database 
storage,  Geographic  Information  System  (GIS)  displays,  etc.).  This  proposed  transmit  architecture  for  AIS 
(shown  in  Figure  3)  is  based  on  the  IALA  model  described  above.  Each  of  the  major  components  of  the 
proposed  architecture  is  described  in  the  sub-sections  below. 
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Figure  3.  Proposed  AIS  transmit  architecture. 


Information  Routing  Notes  (see  letters  in  Figure  3,  the  AIS  message  types  are  explained  in  Table  1,  the 

ASM  Function  Identification  (FI)  is  explained  in  Table  2,  the  Designated  Area  Code  (DAC)  used  in  the 

ASM  is  367): 

A  -  AIS-SM  is  used  to  program  the  AIS-PSS  (base  stations)  for  AIS  Messages:  4,  17  (optional),  20,  23 

(optional)  and  24  (optional).  The  AIS-PSS  generates  AIS  Messages  7  and  13  automatically  upon  receipt 
of  AIS  Message  6  or  12  respectively.  The  AIS-SM  can  also  program  AIS  AtoNs  for  AIS  Message  21 
(optional)  or  the  AIS  Base  Station  for  AIS  Message  21  (optional  Synthetic  or  Virtual  AtoN). 

B  -  A  Client  Process  is  used  to  collect  information  from  the  Users  and  generate  NMEA  sentences  to  initiate 
(telecommands)  AIS  Messages:  10,  15,  16,  22,  and  23  (optional).  This  Client  Process  could  be  part  of 
GUI  C2  System.  This  same  system  could  also  be  used  to  generate  AIS  Messages  25  and  26  and  potential 
AIS  Message  21. 

C  -  The  ASM  Manager(s)  feed  a  managed  stream  of  NMEA  sentences  through  the  AIS  Router  to  the  AIS- 
PSS  to  generate  AIS  Messages:  6,  8,  12,  14,  25,  and  26.  It  is  also  used  to  manage  any  AIS  transmit 
messages  created  by  clients  and  sent  to  the  AIS-PSS  as  VHF  Datalink  Message  (VDM)  type  NMEA 
sentences. 

D  -  The  Users  create  ASMs  (and  text  messages)  in  a  client  process  or  GUI,  these  are  embedded  in  NMEA 
sentences  and  sent  to  the  ASM  Manager  (DAC/FIs:  367/22,  367/35,  367/29,...). 

E  -  The  ASM  Manager  requests  Environmental  ASMS  from  NOAA  PORTS  (DAC:  367,  FI:  22). 

F  -  Other  Database  processes  retrieve  data,  format  into  ASMs  (and  potentially  text  messages)  embedded  in 
NMEA  sentences  and  forward  to  them  to  the  ASM  Manager  for  transmission  (DAC/FIs:  367/22,  367/35, 
367/29,...). 
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The  primary  component  that  implements  the  AIS-LSS  is  an  “AIS  Router;”  so  called,  because  it  is 
responsible  for  routing  the  AIS  data  between  the  AIS  service  clients  and  the  AIS-PSS.  A  market  survey 
conducted  by  RDC  identified  four  major  commercial  vendors  that  supply  AIS  Routers  as  part  of  their  AIS 
shoreside  network  software  [7].  All  of  the  software  packages  allow  for  multiple  client  connections 
(examples  shown  across  the  top  of  the  box);  each  client  connection  typically  has  username  and  password 
authentication  although  this  is  not  required  in  all  cases.  Each  client  can  be  configured  for  different  levels  of 
access  and  data  stream  filtering  (both  send  and  receive).  The  software  also  manages  multiple  connections  to 
AIS  data  streams;  either  from  other  AIS  Routers  (in  a  regional  or  national  hierarchy)  or  from  AIS-PSSs.  All 
of  the  software  packages  implement  data  stream  filtering  on  these  connections  as  well.  Different  vendors 
offer  different  features,  but  in  general  they  all  fully  implement  the  required  capabilities  of  an  AIS-LSS. 

The  other  major  component  of  the  AIS-LSS  is  the  data  logger.  This  is  implemented  by  all  of  the  vendors  in 
a  separate  software  component  that  works  in  conjunction  with  the  AIS  Router.  Typically  this  is  done  using 
an  Oracle  or  Structured  Query  Language  (SQL)  database,  but  in  some  cases,  flat  files  are  used  as  well. 

RDC  conducted  testing  on  the  four  AIS  routers  identified  in  the  market  survey  (Kongsberg  C-Scope, 
Gatehouse  AIS,  Transas  AIS  Network,  and  CNS  DataSwitch).  Copies  of  each  of  software  were  obtained  and 
installed  on  a  test  bed  at  RDC,  running  the  software  on  the  same  computers  to  allow  relative  performance 
comparisons.  The  systems  were  run  through  a  series  of  tests  that  can  be  characterized  into  two  categories: 
basic  and  performance.  The  tests  were  designed  to  assess  the  performance  of  the  systems  in  regards  to 
routing  functionality  and  the  criteria  that  the  project  sponsor  thought  most  important:  raw  throughput  speed 
and  maximum  number  of  clients  possible.  Database  storage,  analytics,  and  display  capabilities  were  not 
evaluated,  although  all  of  the  systems  have  these  capabilities. 

Complete  details  on  the  testing  performed  can  be  found  in  [7]  but  the  results  are  summarized  here.  From  a 
performance  standpoint,  any  of  the  four  commercial  systems  would  be  suitable  for  the  AIS  router.  The 
overall  aggregate  traffic  load  in  the  United  States  is  currently  about  600  messages  per  second.  The  systems 
tested  could  support  from  3,900  to  17,000;  all  well  above  the  current  maximum.  The  numbers  of  clients 
supportable  ranged  from  35  to  250.  CNS  supported  the  most;  however,  all  of  the  other  systems  have 
scalable  client  modules  that  would  allow  for  expansion  to  almost  an  unlimited  number  of  clients  by  adding 
client  modules  (the  reported  client  counts  are  for  a  single  instance  of  the  client  server  modules).  How  many 
clients  are  required,  has  not  been  determined. 

The  study  only  assessed  performance  for  a  few  specific  criteria;  all  of  the  commercial  software  has  much 
more  functionality  than  that  assessed.  Much  of  this  functionality  would  be  important  for  the  overall  system, 
and  some  of  the  functionality  would  impact  the  performance  results.  For  example,  setting  different  filters  for 
each  client  increases  the  Central  Processing  Unit  (CPU)  loading;  especially  if  geographic  filters  are  used. 
One  of  the  lessons  learned  from  the  study  was  that  the  system  settings  can  be  critical  to  performance. 

2.3  AIS  Router 

2.3.1  AIS  Router  Test  Results 

Another  lesson  learned  was  that  an  overall  architecture  for  an  AIS  network  that  supports  full  two-way 
communications  needs  to  be  developed.  Part  of  this  architecture  design  needs  to  include  trade-offs  on  data 
flow  and  data  storage  at  the  local,  regional,  and  national  levels.  For  example,  most  of  the  vendors  in  this 
study  would  recommend  down  sampling  the  data  as  it  is  aggregated  at  the  regional  and  then  national  levels 
and  only  store  the  full  time -rate  data  at  the  local  (or  at  most  regional)  levels.  Additionally,  in  order  to 
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specify  the  hardware  and  software,  the  maximum  number  of  clients  required  to  be  supported  at  each 
connection  level  (local,  regional,  national)  needs  to  be  determined.  This  nationwide  architecture  is  not 
reflected  in  Figure  3. 

2.3.2  ASM  Manager 

The  ASM  Manager  is  software  that  adds  additional  necessary  functionality  to  the  “AIS  router.”  This  is  not 
available  off-the-shelf  currently,  so  software  was  developed  to  layer  this  functionality  on  top  of  an  AIS 
router.  This  program  was  designed  to  shield  the  message  creator  from  the  details  of  the  base  station 
locations  and  manage  ASM  transmissions  by  performing  the  following  functions: 

G  -  Ensure  messages  are  valid  before  transmission. 

H  -  Monitor  VDL  and  ASM  demand  and  adjusts  the  transmit  rate  so  as  to  not  overload  the  VDL. 

I  -  Allow  for  user-specified  priorities  along  with  prioritization  based  upon  message  type  and  content. 

J  -  Determine  if  a  message  should  be  transmitted  from  a  given  transmitter  based  upon  location. 

K  -  Ensure  messages  are  transmitted;  keep  messages  in  the  queue  until  acknowledgement  is  received  from 
the  BS  that  they  were  transmitted. 

L  -  Allow  for  acknowledgement  of  transmission  to  be  routed  back  to  the  user. 

M  -  Manage  the  repetition  of  messages  that  need  to  be  retransmitted  on  a  periodic  basis. 

ASM  Manager  accepts  Broadcast  Binary  Message  (BBM)-type  NMEA  sentences  containing  environmental 
messages,  waterways  management  messages,  text  messages  and  geographic  notices  from  various  data  feeds. 
ASM  Manager  stores  those  messages  in  its  internal  queue.  At  periodic  intervals,  ASM  Manager  forwards 
messages  to  a  Data  Switch(DS).  ASM  Manager  prioritizes  and  limits  the  maximum  number  of  messages 
that  are  output  each  minute  based  upon  its  configuration  parameters  (maximum  number  of  messages  in  a 
report  and  maximum  number  of  reports  per  minute)  which  are  set  to  maintain  a  certain  level  of  VDL 
loading. 

ASM  Manager  has  a  built-in  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP)  server  for  receiving 
BBM  sentences  from  various  data  feeds.  ASM  Manager  also  has  a  built-in  TCP/IP  client  and  Extensible 
Markup  Language  (XML)  parser  for  fetching  data  from  the  NOAA  Physical  Oceanographic  Real  Time 
System  (PORTS)  server  at  a  user-configurable  rate.  Typically  ASMs  are  retrieved  from  the  PORTS  server  at 
a  3 -minute  update  rate. 

ASM  Manager  has  a  built-in  mechanism  for  detecting  and  purging  expired  messages.  All  messages  get 
time-stamped  upon  reception  for  use  if  there  is  no  time  of  data  in  the  message  itself.  For  environmental  and 
geographic  notice  messages,  ASM  Manager  parses  the  date  and  time  from  the  incoming  message  and  uses 
that  time  for  detecting  message  expiration.  For  other  message  types,  the  time  of  reception  is  used  for 
detecting  expired  messages.  The  expiration  period  for  geographic  notice  messages  is  encoded  in  the  binary 
message.  For  other  message  types  the  expiration  period  is  specified  in  the  configuration  file.  Expired 
messages  are  purged  from  the  queue  prior  to  sending  data  to  a  DS. 

ASM  Manager  decodes  station  ID,  data  type  and  sub-type  for  received  messages.  If  a  message  with  the 
same  station  ID  and  data  type  and  sub-type  and  same  DAC  (either  366  or  367)  and  same  FI  (either  1,  22,  29, 
33,  or  35)  is  already  in  the  message  queue,  it  gets  replaced  with  the  updated  information.  Message  priority, 
number  of  times  message  was  delayed,  number  of  times  message  failed  to  transmit  and  the  next  send  time 
are  carried  over  from  the  obsolete  message  to  the  updated  message. 
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ASM  Manager  sorts  messages  by  priority  and  limits  the  number  of  messages  that  get  transmitted  every 
minute  (set  via  configuration  parameters),  so  as  not  to  overload  the  AIS  VDL.  The  message  base  priority 
can  vary  from  1  to  10,  with  1  being  the  highest  priority.  Messages  that  fail  transmit  or  get  delayed  (due  to 
too  many  messages  in  the  queue),  get  their  priority  boosted  by  1  for  each  time  that  the  message  is  delayed  or 
fails  transmit  (while  its  base  priority  remains  the  same).  If  a  message  is  transmitted  successfully,  its  fail  to 
transmit  and  delay  counters  get  reset,  so  its  priority  returns  to  the  base  priority.  Since  the  AIS  VDL  is 
organized  into  1 -minute  frames,  ASM  Manager  sends  out  messages  once  a  minute. 

ASM  Manager  monitors  the  AIS  base  station  feedback  for  Addressed  and  Binary  Broadcast 
Acknowledgement  (ABK)  type  NMEA  messages  that  indicate  success  or  failure  of  message  transmission.  In 
case  a  message  is  not  acknowledged,  that  message  is  put  back  into  the  transmit  queue  and  its  failed  transmit 
counter  is  incremented.  Messages  that  fail  to  transmit  are  scheduled  for  retransmit  in  the  next  minute’s 
transmit  cycle. 

ASM  Manager  can  accept  metadata  along  with  the  BBM  sentence  (repeat  rate,  priority,  and  area  of 
transmission)  in  RDC  proprietary  type  NMEA  sentences  (PRDC).  ASM  Manager  can  filter  out  messages  by 
area  of  transmit  specified  in  PRDC  sentence  if  filtering  is  turned  on.  PRDC  and  BBM  sentences  are 
expected  to  follow  the  following  sequence:  [optional  PRDC] [BBM  1  of  x]...[BBM  x  of  x], 

ASM  Manager  checks  for  various  error  conditions  and  in  case  of  errors,  it  generates  email  alerts  about  the 
outages.  To  reduce  the  number  of  emails,  a  single  email  alert  notice  is  generated  in  a  24-hour  period  that 
contain  all  errors  and  alerts  that  occurred  since  the  last  email  was  generated. 

ASM  Manager  provides  configurable  monitoring  and  logging  capabilities  and  an  interactive  user  interface. 
The  user  interface  allows  turning  on  and  off  display  of  the  message  queue  (before  and  after  each  transmit), 
display  of  message  information,  deleting  messages  from  the  queue,  and  stopping  program  operation. 

2.3.3  ASM  Manager  Logic 

The  following  sections  summarize  the  logical  steps  that  the  ASM  Manager  performs  in  completing  various 
processes. 

2.3.3. 1  Input  Processes 
Server  Process 

•  Wait  for  connections  on  TCP/IP  port. 

•  Once  connection  opened,  spawn  off  a  new  thread  to  handle  the  client  and  free  up  server  port  to 
accept  new  connections. 

•  Receive  NMEA  4.0  TAG  [8]  blocks  and  BBM  sentences.  Maintain  data  received  from  each  open 
client  connection  in  a  separate  processing  queue. 

•  Parse  $PRRDC  sentence  that  contains  ASM  parameters: 

-  Repeat  interval 

-  Priority 

-  Geographic  area  for  transmission 

•  Parse  each  BBM  sentence  to  ensure  the  sentence  is  correct,  get  time  parameters  from  message. 

•  NOTE:  if  ASM  Manager  receives  a  BBM  sentence  that  is  an  unknown  DAC/FI  then  it  will  be 
discarded. 

•  Add  the  message  into  the  appropriate  queue  for  transmission. 
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Client  Process 

•  Initiate  connections  (to  NOAA  PORTS)  at  the  defined  interval. 

•  Pass  parameters:  location  and  maximum  number  of  slots  to  use  in  each  message. 

•  Parse  each  BBM  sentence  and  ensure  sentence  is  correct,  get  time  parameters  from  message. 

•  NOTE:  if  ASM  Manager  receives  a  BBM  sentence  that  is  an  unknown  DAC/FI  then  it  will  be 
discarded. 

•  Add  the  message  into  the  appropriate  queue  for  transmission. 

Queue  Process 

•  When  adding  message  into  the  queue,  check  to  see  if  it  is  a  newer  version  of  a  message  already  there 
(based  upon  DAC/FI/Msg  ID/Sensor  ID/SubType  fields).  If  it  is,  delete  the  old  message  and  add  the 
new  message  with  a  priority  of  1  less  than  the  message  just  deleted. 

•  Queue  has  the  following  fields 

-  Serial  number  -  give  the  message  a  sequential  number  for  tracking 

-  Type  of  data  (static  or  dynamic) 

-  Message  identifiers  -  info  to  enable  checks  for  new  messages  of  same  type 

•  DAC,  FI,  sensor  id/message  ID 

-  Time  into  queue  -  timestamp  of  when  placed  in  queue 

-  Time  expires  -  time  the  message  is  no  longer  valid  -  this  is  an  explicit  parameter  in  the 
Geographic  Notices.  Messages  without  this  parameter  get  assigned  the  default  value  from  the 
configuration  file 

Repeat  interval  -  how  often  (minutes)  to  repeat  the  message  (0  =  never) 

-  Priority  -  message  priority,  1  (high)- 10  (low) 

•  If  the  user  has  specified  a  priority  then  message  starts  with  this 

•  Default  for  dynamic  data  is  5 

•  Default  for  static  data  is  10 

-  Data  (BBM  sentence  wrapped  into  TAG  block) 


Output  Process 

•  Perform  Queue  management  before  each  transmit. 

o  Remove  messages  that  have  expired 

•  Every  minute  select  N  messages  from  the  queue  for  transmission. 

o  N  =  configurable  parameter 

o  Messages  are  selected  based  on  highest  priority  messages  that  have  in-queue  times  earlier 
than  current  time 

•  Open  a  connection  to  the  DS  and  send  the  N  messages  wrapped  in  TAG  blocks. 

•  Wait  for  Acknowledgement  (ACK)  messages  back  from  the  DS  (from  the  AIS  base  station). 

•  Once  ACK  messages  are  received,  delete  the  messages  from  the  queue. 

•  Generate  an  alert  if  ACK  messages  are  not  received. 

•  If  the  message  being  deleted  has  a  non-zero  repeat  interval  put  it  back  into  the  queue  with  an  in¬ 
queue  time  equal  to  the  current  time  plus  the  repeat  interval. 

•  For  each  message  that  is  left  in  the  queue,  decrement  the  priority  by  1. 


2.3.4  AIS-PSS  Layer 

Although  the  IALA  model  for  the  AIS-PP  layer  includes  an  additional  AIS-PCU  sub-layer,  the  USCG 
installations  do  not  use  this.  Any  functionality  of  the  AIS-PCU  layer  is  handled  by  the  AIS  Fixed  Stations. 
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In  the  case  of  the  Tampa  test  bed  this  is  an  L-3  Protec  base  station.  For  the  Columbia  River,  this  is  two 
SAAB  R-40  base  stations.  Louisville  is  currently  a  SAAB  R-40  base  station  but  this  is  being  transitioned  to 
an  L-3  Protec.  The  Stellwagen  Bank  test  bed  uses  an  L-3  AtoN  transmitter. 

2.4  Base  Station  Testing  Results 

There  are  two  methods  for  delivering  the  information  to  an  AIS  base  station  so  that  it  can  transmit  an  AIS 
binary  message;  using  a  NMEA  BBM  (or  Addressed  Binary  Message  (ABM))  sentence  and  by  using  a 
VDM  sentence.  These  methods  are  discussed  in  more  depth  in  Section  3.1  below.  In  addition,  there  are  two 
main  channel  access  modes  that  a  base  station  can  use:  Fixed  Access  Time  Division  Multiple  Access 
(FATDMA)  and  Random  Access  Time  Division  Multiple  Access  (RATDMA).  In  general  it  is  more 
efficient  for  the  VDL  loading  for  a  base  station  to  reserve  sufficient  slots  and  use  FATDMA  for  all 
transmissions.  This  was  examined  in  our  VDL  report  [9].  However,  if  RATDMA  mode  is  not  enabled,  on 
some  base  stations,  some  transmissions  may  not  occur,  so  in  general  RATDMA  must  be  enabled. 

The  IALA  and  International  Electrotechnical  Commission  (IEC)  62320-1  Ed.l  standards  are  not  totally 
clear  on  exactly  how  a  base  station  should  act  in  various  combinations  of  message  types  (BBM  vs.  VDM) 
and  channel  access  modes.  IEC-62320-1  [10]  in  paragraph  6. 3.4. 8  describes  the  base  station  response  to 
VDM  input  as  the  following:  [Note:  Figure  4  provides  Figure  5  from  the  quotation.] 

The  Base  Station  shall  transmit,  on  the  VDL,  VDM  sentences  received  on  the  PI.  FATDMA  shall  be 
used  as  the  access  scheme  for  transmission.  RATDMA  may  also  be  configured  for  use.  The  following 
rules  shall  be  used  for  VDL  transmission  (as  shown  in  Figure  5): 

1.  the  VDL  message  shall  be  transmitted  in  available  FATDMA  slots;  NOTE  Available  FATDMA 
slots  are  local  ‘L  ’  slots  without  planned  ECB  transmissions. 

2.  if  FATDMA  slots  are  not  available  within  4-seconds,  RATDMA  shall  be  used; 

3.  if  RATDMA  is  not  available,  and  if  there  is  an  available  FATDMA  slot  within  6-minutes,  it  shall 
be  used; 

4.  if  FATDMA  and  RATDMA  are  not  available,  there  shall  be  no  transmission  and  the  VDM  is 
discarded. 

IEC-62320-1  is  silent  on  what  the  response  should  be  to  a  BBM  sentence.  In  order  to  assess  how  some  base 
stations  actually  respond,  RDC  conducted  tests  on  both  the  L-3  Protec  and  Saab  R-40  base  stations.  The 
results  are  detailed  in  the  sub-sections  below. 


2.4.1  L-3  Protec  Base  Station 

With  BBM  sentences  and  FATDMA-only  mode,  only  messages  that  can  be  sent  in  the  reserved  slots  in  1 
minute  get  transmitted.  ABK  sentences  stating  that  transmission  is  not  possible  are  output  for  the  remainder  at 
60  seconds  after  the  sentences  were  presented  to  the  base  station.  With  VDM  sentences  the  radio  will  try  over 
a  longer  interval  (the  IEC  standard  requires  6  minutes)  but  due  to  memory  limitations  only  scheduled  2 
minutes  worth,  which  was  indicated  by  Transmit  Feedback  Report  (TFR)  sentences.  The  radio  then 
transmitted  messages  for  an  additional  2  minutes.  This  anomaly  is  being  discussed  with  the  L-3  manufacturer. 


With  RATDMA  enabled,  the  radio  performed  as  expected.  With  BBM  sentences,  as  many  messages  as 
could  be  sent  in  the  4-second  response  window  were  sent;  any  reserved  slots  in  that  4-second  window  were 
used.  ABKs  indicating  negative  transmission  were  output  at  the  end  of  the  4-second  (150  slots)  window  for 
any  other  messages  that  could  not  be  sent.  The  same  response  was  seen  for  VDM  sentences.  TFRs  were 
output  for  all  sentences. 
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Figure  4.  Flow  diagram  for  AIS  BASE  station  response  to  VDM  input. 

(Figure  5  from  IEC  62320- 1  [10]) 

2.4.2  Saab  R-40  Base  Station 

In  FATDMA-only  mode  we  could  not  get  the  radio  to  transmit  based  on  a  BBM  sentence.  This  flaw  is  being 
discussed  with  Saab.  With  VDM  sentences  the  radio  would  transmit  the  messages  in  the  reserved  slots  — 
even  waiting  beyond  1  minute  for  an  open  slot  reservation  in  order  to  transmit. 

In  FATDMA+RATDMA  mode  the  radio  transmitted  the  BBMs  instantly.  The  radio  did  not  appear  to 
implement  the  randomization  algorithm  described  in  ITU-R  M.1371  [3]  with  transmissions  randomized  over 
the  4-sec  interval.  Instead,  it  appeared  the  messages  were  transmitted  instantly  and  in  succession.  Reserved 
slots  were  not  used.  With  VDM  sentences,  the  performance  was  the  same.  In  discussions  with  Saab,  they 
claimed  that  their  randomization  algorithm  although  different  than  that  in  1371  was  approved  by  Bundesamt 
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fur  Seeschiffahrt  und  Hydrographie  which  certifies  that  the  R40  AIS  base  station  complies  with  the  latest 
specifications  contained  in  the  new  IEC62320-1  Performance  Standard. 

2.4.3  Architecture  Implications 

Since  the  USCG  has  standardized  on  the  L-3  Protec,  the  architecture  implications  are  based  on  the  L-3 
performance.  Using  a  1 -minute  interval  for  message  queuing  on  the  ASM  Manager  works  well  since  the  L-3 
only  uses  a  1 -minute  interval  for  BBM  sentence  transmission.  If  RATDMA  mode  is  going  to  be  enabled  and 
it  is  still  desired  that  most  of  the  transmissions  are  in  reserved  slots,  then  there  needs  to  be  sufficient 
reserved  slots  in  each  4-second  window  to  handle  the  ASM  manager  traffic  (meaning  about  15  times  as 
many  slots  reserved).  If  RATDMA  can  be  disabled  then  it  is  more  efficient  for  the  VDL,  since  slots  for  the 
ASM  manager  traffic  can  be  spaced  across  the  entire  1 -minute  frame. 

3  MAPPING  AIS  TRANSMIT  MESSAGES  TO  ARCHITECTURE 

The  AIS  does  a  great  job  informing  the  VTS  and  Sector  Command  Center  (SCC)  of  vessel  position  and 
identification,  but  in  addition,  AIS  can  be  a  very  effective  VTS/SCC  tool  for  communication.  AIS 
accomplishes  this  by  utilizing  the  transmit  capability  and  AIS  binary  messages  or  ASMs.  For  clarification 
purposes,  transmit  is  defined  to  include  both  AIS  broadcast  and  addressed  messages.  The  current  AIS 
specification,  ITU- 137 1-4  [3]  defines  27  different  AIS  messages  shown  in  Table  1.  Some  of  these  message 
types  can  be  grouped  into  categories  applicable  to  AIS  transmit:  message  types  4,  17,  20,  and  24  are  base 
station  messages;  message  types  10,  11,  15,  16,  20,  22,  and  23  can  be  considered  telecommands  that  can  be 
used  by  a  VTS  for  channel  management;  message  types  12,  13,  and  14  can  be  used  for  safety-related  text 
messages;  and  message  types  6,  7,  8,  21,  25,  and  26  are  binary  messages  that  can  be  used  for  information 
transfer.  Table  2  provides  the  valid  function  identifiers  for  DAC  366/367. 


Table  1.  AIS  message  types. 


ID# 

AIS  Message  Description 

1,2,3 

Position  Reports  -  autonomous,  assigned,  or  interrogated 

4 

Base  Station  Report  -  UTC/date,  position,  slot  number. 

5 

Class  A  Report  -  static  and  voyage  related  data 

6,  7,8 

Binary  Message  (ASM)  -  addressed,  acknowledge  or  broadcast 

9 

SAR  aircraft  position  report 

10,  11 

UTC/Date  -  enquiry  and  response 

12,  13,  14 

Safety  Text  Message  -  addressed,  acknowledge  or  broadcast 

15 

Interrogation  -  request  for  specific  messages 

16 

Assignment  Mode  Command 

17 

Binary  Message  -  DGNSS  Correction 

18,19 

Class  B  Reports  -  position  &  extended 

20 

Data  Link  Management  -  reserve  slots 

21 

AtoN  Report  -  position  &  status 

22 

Channel  Management 

23 

Group  Assignment 

24 

Class  B  Static  Data 

25 

Binary  Message  (ASM)-  single-slot 

26 

Binary  Message  (ASM)  -  multi-slot  (STDMA) 

27 

Long-range  AIS  broadcast  message 
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Table  2.  Valid  function  identifiers  for  DAC  366/367. 


FI 

Description 

16 

Passenger  and  Crew  Count 

17 

Synthetic  Targets  Message 

22 

Geographic  Notice  USCG 

29 

Linked  Text 

33 

Environmental  USCG 

35 

Waterways  Management  USCG 

55 

USCG  Encrypted  Text  Message 

56 

USCG  Encrypted  Position  Report 

57 

USCG  Encrypted  Static  Data 

58 

USCG  Encrypted  Target  of  Interest 

63 

Water  Level 

3.1  Message  Transmission  Options 

There  are  three  ways  to  have  a  base  station  transmit  an  AIS  message;  each  method  has  pros  and  cons,  and 
some  AIS  messages  are  better  suited  to  certain  methods.  Each  of  the  methods  and  the  recommended  AIS 
messages  are  described  in  the  following  subsections. 

3.1.1  Base  Station  Programming 

A  typical  base  station  (such  as  the  L-3  Protec)  can  be  programmed  to  generate  some  AIS  messages 
automatically.  The  AIS-SM  layer  does  the  programming  -  whether  this  is  third-party  software  such  as 
Maestro  or  the  base  station  vendor’s  software  (L-3  Base  Station  GUI).  The  messages  are  configured  and 
assigned  to  a  repetitive  transmit  schedule.  Slots  can  also  be  reserved  for  these  messages.  There  are  some 
AIS  messages  that  would  be  difficult  to  create  and/or  manage  by  one  of  the  other  two  transmit  methods  and 
so  should  be  sent  using  this  method.  The  messages  that  fall  into  this  category  are: 

•  AIS  Message  4  -  base  station  report. 

•  AIS  Message  17  -  Differential  Global  Navigation  Satellite  System  (DGNSS)  corrections  broadcast. 

•  AIS  Message  20  -  data  link  management. 

•  AIS  Message  24  -  extended  base  station  information  (if  supported  by  the  base  station). 

•  AIS  Message  22  -  channel  management  (if  using  Area-based  channel  management). 

•  AIS  Message  21  -  AtoN  (if  only  a  few  virtual  or  synthetic  aids,  with  static  parameters). 

3.1.2  NMEA  Sentence  Programming 

A  base  station  supporting  NMEA  4.0  can  be  configured  to  transmit  most  AIS  messages  using  various 
NMEA  sentences.  In  this  case,  a  client  application  could  create  the  appropriate  NMEA  sentences  and  send 
them  through  the  network  to  the  base  station.  The  base  station  uses  the  information  in  the  sentences  to  create 
and  transmit  the  AIS  messages.  Most  messages  that  a  base  station  can  transmit  can  be  configured  and  sent  in 
this  manner.  The  advantage  of  this  method  vs.  Base  Station  Programming  is  that  a  client  application  (not 
just  the  AIS-SM)  could  request  the  transmission  of  the  AIS  message.  The  advantage  of  this  method  vs. 
Directly  Created  AIS  Messages  is  that  this  method  does  not  require  the  client  to  know  anything  about  the 
VDL  or  the  current  slot  map;  the  base  station  handles  that  when  it  creates  the  AIS  messages  from  the 
information  in  the  NMEA  sentences.  The  messages  that  are  recommended  to  use  this  method  are: 

•  AIS  Message  6  -  addressed  binary  message. 

•  AIS  Message  8  -  broadcast  binary  message. 
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•  AIS  Message  12  -  addressed  safety-related  text. 

•  AIS  Message  14  -  broadcast  safety-related  text. 

•  AIS  Message  25  -  short  unscheduled  binary  transmission. 

•  AIS  Message  26  -  scheduled  binary  transmission. 

•  AIS  Message  22  -  channel  management  (if  used  for  specific  station  channel  management). 

•  AIS  Message  10  -  request  Universal  Time  Coordinated  (UTC)  date/time  (this  is  not  supported  under 
the  current  L-3  firmware  but  will  be  in  the  next  revision). 

•  AIS  Message  1 5  -  request  for  specific  message(s)  (base  station  will  generate  an  ABK  for  this  so 
gives  additional  status). 

•  AIS  Message  16  -  assignment  mode  (especially  if  assigning  slots  that  then  need  to  be  reserved). 

•  AIS  Message  21  -  AtoN  (for  virtual  or  synthetic  aids,  with  parameters  that  need  to  be  changed  by 
the  client  application  periodically  -  perhaps  due  to  monitoring). 

3.1.3  Directly  Created  AIS  Message 

A  base  station  can  be  forced  to  transmit  any  AIS  message  by  embedding  the  AIS  message  in  a  VDM 
sentence  and  sending  that  to  the  base  station.  This  allows  tremendous  flexibility;  however,  it  puts  the  entire 
burden  of  the  AIS  message  creation  and  VDL  management  onto  the  client.  The  L-3  Protec  base  station  will 
generate  a  TFR  sentence  back  to  the  client  upon  receipt  of  a  VDM  which  is  very  helpful;  however,  this  is 
not  required  by  the  NMEA  standard  and  thus  cannot  be  expected  with  all  base  stations.  There  are  several 
AIS  messages  that  would  be  very  difficult  to  create  and  manage  using  this  method,  and  thus  are  not 
recommended  for  this  transmission  method  (AIS  4,  17  and  20  for  example).  The  messages  that  are 
recommended  to  use  this  method  are: 

•  AIS  Message  16  -  assignment  mode  (for  assigned  rate  mode  only). 

•  AIS  Message  21  -  AtoN  (for  virtual  or  synthetic  aids,  if  too  many  for  the  base  station  to  manage 
using  other  methods). 

•  AIS  Message  24  -  extended  base  station  information  (if  base  station  does  not  support  sending  the 
message  automatically  -  this  is  the  case  with  the  L-3  Protec). 

4  INTEGRATION  WITH  EXISTING  USCG  AIS  SYSTEMS 

The  NAIS  Acquisition  project  has  an  AIS  architecture  that  includes  an  AIS  router,  the  CNS  Systems™ 
DataSwitch.  In  an  effort  to  converge  the  development  efforts  and  allow  for  easier  integration  of  efforts,  the 
RDC  Transmit  Architecture  (including  the  ASM  Manager)  was  designed  to  work  in  conjunction  with  this 
AIS  router.  Technically  the  integration  of  the  proposed  transmit  architecture  with  NAIS  (see  Figure  3) 
would  be  very  simple;  just  the  addition  of  the  ASM  manager  next  to  the  CNS  DataSwitch. 

An  initial  test  of  this  including  the  ASM  Manager  in  the  NAIS  Permanent  Transceive  system  has  been 
proposed  by  RDC.  This  addition  is  shown  in  Figure  5.  The  system  changes  needed  are  indicated  in  the 
diagram  by  the  letters  A,  B,  and  C.  These  changes  are: 

A.  DataSwitch  Changes.  Add  account  for  ASM  Manager. 

•  This  account  is  independent  of  account(s)  on  the  NAIS  side. 

•  DataSwitch  routes  traffic  based  upon  account  settings. 

•  Think  of  it  as  adding  another  computer  to  an  Ethernet  Switch-  no  impact  to  existing  computers  as 
long  as  the  switch  can  handle  the  load. 
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o  RDC  testing  shows  that  DataSwitch  can  handle  a  LOT  more  loading  than  it  is  currently 
under. 

B.  ASM  Manager  to  DataSwitch  Physical  Connection. 

•  Either  Serial  or  Ethernet. 

o  Serial:  ASM  Manager  computer  needs  to  be  local  to  DataSwitch. 
o  Ethernet:  requires  authorization  for  ASM  Manager  to  be  on  OneNet  (if  DataSwitch  is  on 
OneNet?). 

C.  ASM  Manager  connection  to  Internet. 

•  If  ASM  Manager  is  on  OneNet  then  use  OneNet  to  access  Internet. 

•  If  ASM  Manager  is  using  serial  connection  to  DataSwitch  then  need  access  to  a  separate  network 
connection  (either  use  existing  or  install  cable/DSL/cellular  connection). 


NOAA PORTS 


Local  serial  or 


Legend: 

ASM  =  Application  Specific  Message 
HCS  =  Harbor  Control  System 
PSS  =  Physical  Shore  Stations 


s. 


Maestro 


[  ASM  NAIS  Admin 

Top  Connections 


DataSwitch 


Bottom  Connections 
PSS I  PSSZ  PSSN 


Figure  5.  NAIS  with  RDC  transmit  Phase  1. 


There  are  currently  two  USCG  programs  with  AIS  base  stations  -  VTS  and  NAIS.  Each  of  these  programs 
uses  a  different  architecture,  which  is  currently  not  compatible  with  sharing  of  the  AIS  base  stations.  PAWSS 
is  a  major  acquisition  project  to  build  new  Vessel  Traffic  Services  where  necessary  and  replace  existing 
systems.  VTS  currently  (see  Figure  6)  uses  a  direct  connection  (serial  over  Internet  Protocol  (IP))  from 
PAWSS  to  the  Physical  Shore  Stations  (PSS),  which  typically  consists  of  a  single  AIS  base  station.  In  contrast, 
NAIS  uses  a  backbone  architecture  based  upon  the  CNS  Systems  DataSwitch  to  connect  to  the  PSSs. 
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PAWSS 


Figure  6.  VTS  with  PAWSS,  current  configuration. 


There  has  been  some  discussion  on  how  to  allow  the  two  systems  to  share  the  PSSs.  One  concept  would  be 
to  build  in  dual  connections  to  each  PSS  and  have  the  two  systems  operate  in  parallel  (see  Figure  7)  where 
NAIS  is  in  green  and  VTS  (PAWSS  is  in  light  blue).  However,  this  requires  additional  communications 
lines  to  each  PSS  and  thus  is  costly.  However,  the  RDC’s  AIS  Transmit  architecture  could  be  used  as  a  way 
to  allow  these  two  systems  to  operate  together;  specifically,  by  using  the  DataSwitch  (DS)  to  provide  the 
sharing  of  the  PSSs  (see  Figure  8).  This  eliminates  the  cost  of  the  extra  communications  links,  allows  for 
AIS  Transmit  to  be  integrated  into  the  architecture  through  the  DS,  and  includes  the  addition  of  the  ASM 
Manager  as  a  value-added  component.  In  Figure  8,  an  additional  “backup  connection”  box  is  shown  to 
indicate  that  due  to  the  criticality  of  the  VTS  function,  there  must  be  a  backup  to  the  DS  component.  This 
backup  could  either  be  a  redundant  DS  or  a  failover  to  direct  connections  between  PAWSS  and  the  PSSs. 
Figure  9  shows  the  proposed  AIS  Transmit  Architecture  with  both  NAIS  and  PAWSS. 


Figure  7.  NAIS  overlay  to  VTS  PAWSS. 
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Figure  8.  NAIS  integrated  with  PAWSS. 


Figure  9.  AIS  transmit  architecture  with  NAIS  and  PAWSS. 


5  TRANSITION  STRATEGY 


5.1  Tampa  Transition 

Tampa  is  the  oldest  and  most  mature  test  bed,  making  it  a  prime  candidate  for  transition  to  being  fully 
integrated  into  an  operational  VTS.  Various  transition  options  for  the  entire  VTS  system  were  proposed  in 
2010  [1 1],  None  of  these  were  selected  and  in  201 1,  a  proposed  transition  strategy  for  just  Tampa  was 
developed  [12]  with  the  goal  of  moving  the  Tampa  test  bed  to  an  operational  system.  Under  this  transition 
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plan,  there  would  have  been  little,  if  any,  impact  on  the  daily  routine  of  the  VTS  watchstanders.  With  the 
exception  of  new  computers  onsite  for  running  the  back-end  processes,  the  VTS  watchstander  would  have 
seen  little  change  as  a  result  of  VTS  Tampa  assuming  full  responsibility  for  the  system.  The  major  impact  of 
this  transition  would  have  been  centered  on  the  maintenance  and  repair  of  the  system.  There  are  specific 
functions  that  RDC  currently  performs,  such  as: 

1 .  AIS  operating  software  maintenance 

2.  AIS  operating  software  upgrades 

3.  Network  maintenance  (off-site) 

4.  Incoming  data  issues 

5.  Software  troubleshooting  and  repair 

6.  Hardware  troubleshooting  and  repair 

7.  Initial  training 

8.  Updating  of  all  documentation 

Under  the  planned  post-transition  state,  all  of  these  functions  would  have  been  the  responsibility  of  Tampa’s 
VTS  Director. 


After  discussion  with  VTS  Tampa,  the  VTS  Program  Manager,  and  NOAA,  it  was  decided  that  the  best 
course  or  action  going  forward  for  transitioning  Tampa  to  Operational  status  was  to  turn  over  Physical 
Oceanographic  Real  Time  System  (PORTS)  Transmit  operations  to  NOAA.  As  of  the  date  of  this  report,  the 
original  test  bed  in  Tampa  is  in  the  process  of  being  converted  into  an  operational  system  under  the  control 
of  NOAA.  As  part  of  the  transition,  the  architecture  (and  software  processes)  are  being  upgraded  to  the 
current  version  as  shown  in  Figure  2  (currently  parallel  processes  are  being  run  at  RDC  to  generate  both  old 
and  new  message  formats  to  allow  for  a  transition  period  for  the  Tampa  pilots).  Message  Creation  will  be 
automatic  from  PORTS.  The  PORTS  data  is  requested  directly  by  the  ASM  Manager,  which  will 
accomplish  the  Message  Routing.  The  ASM  Manager  will  run  on  a  computer  at  NOAA’s  Silver  Spring,  MD 
location  and  connect  directly  to  the  AIS  base  station  in  Largo,  FL.  NOAA  will  request  an  NAIS  data  feed  in 
order  to  monitor  the  transmissions  from  the  Palmetto  NAIS  receive  site.  It  is  expected  that  this  transition 
will  be  complete  by  September  2013. 

5.2  Columbia  Transition 

The  Columbia  River  test  bed  was  turned  over  to  the  Volpe  Center  in  2010.  Since  the  Volpe  Center  already 
managed  the  base  stations  for  the  Columbia  River  Pilots,  this  was  an  easy  handoff.  In  2013  RDC  worked 
with  Volpe  Center  to  update  the  architecture  and  message  formats  to  the  current  specification.  As  of  the  date 
of  this  report,  this  transition  to  the  new  message  generation  architecture  and  new  message  specifications  is 
in  process.  It  is  expected  that  this  transition  will  be  complete  by  September  2013. 


5.3  Stellwagen  Bank  Transition 

In  2010,  National  Marine  Sanctuary  (NMS)  agreed  to  take  over  operation  of  the  Stellwagen  Bank  AIS 
Transmit  operations  although  RDC  maintained  control  of  the  AIS  transmitter.  This  involved  transferring 
some  processes  and  monitoring  responsibility  from  RDC  to  NMS.  The  Queue  Manager  process  was  moved 
to  Cornell  and  is  monitored  along  with  the  Fetcher/Formatter  that  is  already  there.  The  AIS  Radio  Interface 
(ARI)  remained  running  on  a  computer  at  Provincetown.  System  monitoring  responsibility  shifted  from 
RDC  to  NMS.  This  was  complete  in  August  2010.  The  AIS  base  station  at  Provincetown  was  replaced  with 
an  AIS  AtoN  transmitter  by  UNH  in  Jan  2011. 


Acquisition  Directorate 

Research  &  Development  Center 


18 


UNCLAS//Public  |  CG-926  R&DC  1 1.  Gonin,  et  al.  |  Public 

August  2013 


AIS  ASM  Operational  Integration  Plan 


During  2013,  RDC  has  worked  with  NOAA  to  update  the  system  to  the  current  architecture  and  message 
specification,  although  this  has  not  been  completed  to  date.  The  plan  is  also  to  turn  over  the  transmitter  once 
appropriate  authorizations  are  in  place.  NMS  has  requested  the  frequency  authorizations  for  this  transition. 

5.4  PAWSS  Transition 

Since  2010,  RDC  has  developed  several  options  for  transitioning  PAWSS  into  an  AIS  Transmit  capable 
system.  Several  options  were  proposed  in  2010  [1 1]  but  not  executed.  More  recently,  a  simpler  approach  to 
integrating  PAWSS  was  proposed  to  be  tested  in  three  phases;  although  this  has  been  on  hold  awaiting  the 
completion  of  PAWSS  software  upgrades  to  the  new  version  (MTM300). 

5.4.1  Phase  1  -  PAWSS  DataSwitch  Integration  Verification 

The  purpose  of  this  testing  is  to  demonstrate  that  PAWSS  can  work  (transparently  for  the  VTS  operator)  by 
connecting  to  the  AIS  base  stations  via  a  CNS  DataSwitch  vice  direct  connections.  This  is  important 
because  if  we  change  to  this  configuration  it  enables  the  implementation  of  AIS  Transmit  (in  the  short  term) 
in  all  VTS  ports  without  having  to  modify  PAWSS  at  all.  The  longer  term  solution  is  to  modify  PAWSS  to 
add  in  the  capability  to  create/send  and  decode/display  the  AIS  ASMs,  but  using  a  DataSwitch  also  enables 
the  AIS  base  stations  to  be  shared  more  easily  and  would  be  needed  in  the  future  configuration  anyway.  The 
CNS  DataSwitch  was  selected  for  this  integration  as  opposed  to  some  other  commercial  product  because  it 
is  part  of  NAIS  and  this  would  facilitate  future  integration  of  VTS  into  the  NAIS  network. 

5.4.2  Phase  2  -  PAWSS  DataSwitch  Integration  Operational  Test 

The  purpose  of  this  testing  is  to  demonstrate  that  the  PAWSS-DS  integration  can  work  (transparently  for  the 
VTS  operator)  in  an  operational  setting.  The  plan  is  to  include  the  AIS  Transmit  testing  in  conjunction  with 
the  PAWSS  MTM300  testing  to  be  done  at  VTS  San  Francisco.  The  IATT  for  the  MTM300  (new  version  of 
PAWSS  software)  testing  would  be  extended  to  include  the  AIS  Transmit  testing,  which  would  be  added  on 
at  the  end  of  the  test  period.  Both  qualitative  and  quantitative  assessments  are  planned. 

5.4.3  Phase  3  -  PAWSS  ASM  Integration 

The  final  step  would  be  to  include  the  ability  within  PAWSS  to  both  encode  and  decode  the  ASMs.  This 
would  require  programming  modifications  by  Lockheed  Martin.  A  previous  estimate  was  for  175  man-days 
to  do  this.  The  timeline  for  this  is  totally  a  function  of  USCG  Command,  Control,  and  Communications 
Engineering  Center  (C3CEN)  and  Lockheed  Martin  and  what  priorities  are  set  by  C3CEN/USCG 
Headquarters. 

5.5  SDLC  process 

The  final  transition  effort  has  been  the  initiation  of  the  System  Development  Life  Cycle  (SDLC)  process  for 
the  ASM  Manager.  The  goal  of  this  effort  is  to  get  the  ASM  Manager  accepted  as  an  approved  USCG  C4I 
System  and  authorized  for  use  on  the  CG  OneNet.  This  will  facilitate  implementation  CG-wide  and  will 
help  to  address  many  security  issues. 


6  INTERFACES  TO  OTHER  AGENCIES  (NOAA,  USACE) 

6.1  NOAA 

The  USCG,  NOAA  National  Marine  Sanctuary  (NMS)  and  NOAA  Physical  Oceanographic  Real  Time 
System  (PORTS)  have  been  working  together  to  develop  various  aspects  of  AIS  broadcast  capability 
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through  standards  development,  software  development,  and  field  testing.  USCG  and  NOAA  are 
strengthening  their  partnership  with  the  goal  of  implementing  a  joint,  AIS  Aids  to  Navigation  (AtoN) 
capability  with  both  NMS  and  PORTS  information. 

6.1.1  Roles 

NOAA  National  Marine  Sanctuary  (NMS)  provides  a  variety  of  important  marine  protection  information  to 
the  mariner  such  as: 

•  Seasonal  Management  Areas 

•  Right  Whale  Listening  Buoys 

•  Dynamic  Management  Areas 

•  Areas  to  be  Avoided 

•  Mandatory  Ship  Reporting  Areas 

•  Recommended  Routes 

NOAA's  National  Ocean  Service  that  provides  PORTS,  a  program  that  supports  safe  and  cost-efficient 
navigation  by  providing  ship  masters  and  pilots  with  accurate  real-time  information  such  as  real-time  water 
levels,  currents,  and  other  oceanographic  and  meteorological  data. 

The  USCG  is  the  competent  authority  for  the  Nationwide  AIS  network  and  is  responsible  for  the 
management  and  coordination  of  all  AIS  ASM  transmissions  in  the  US. 


6.1.2  System  Architecture 

A  proposed  demonstration  architecture  is  shown  in  Figure  10.  NOAA  and  the  USCG  have  been  proceeding 
towards  implementing  this  in  the  Chesapeake  Bay,  VA  area  as  a  test. 


Light  blue  =  USCG  RDC,  Green  =  NOAA,  Gray  =  Volpe,  Dark  Blue  =  Stellwagen  Bank 

Figure  10.  USCG-NOAA  Chesapeake  Bay  AIS  transmit  partnership  -  MPI  stands  for  Message  Passing 
Interface. 
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6.2  USACE 

The  USACE  has  been  working  to  implement  their  LOMA  (Lock  Operations  Management  Application) 
system  for  the  past  couple  of  years.  In  addition  to  the  lock  management  functions,  it  is  intended  that  this 
system  also  integrate  with  the  USCG  AIS  system  for  exchange  of  AIS  data  and  sharing  of  transmitters  for 
the  broadcast  of  Marine  Safety  Information  (see  Figure  11).  One  area  that  the  USCG  will  be  working  with 
USACE  directly  is  on  the  implementation  of  broadcasts  of  water  current  information  from  the  lock  current 
models.  The  USACE  is  developing  models  of  the  water  currents  around  the  locks  based  upon  bathymetry, 
water  level,  dam  outflow,  etc.  These  models  generate  a  field  of  water  current  vectors  (see  Figure  12).  RDC 
is  working  with  USACE  to  develop  the  processes  and  procedures  to  select  some  of  these  water  current 
values  from  the  thousands  produced  by  the  model  and  transmit  them  to  the  mariners  via  AIS. 
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Figure  11.  LOMA  system  overview. 
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Figure  12.  Sample  lock  current  modeling  output. 
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Figure  13.  Close-up  of  Figure  12. 
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7  RECOMMENDATIONS 

An  AIS  architecture  that  can  support  the  dissemination  of  electronic  Maritime  Safety  Information  (eMIS), 
based  upon  international  standards  has  been  proposed  by  RDC.  This  architecture  can  support  integration  of 
PAWSS  and  NAIS.  Many  assumptions  were  made  with  regards  to  this  proposed  architecture  and  it’s 
interfacing  to  PAWSS  and  NAIS.  These  assumptions  will  need  to  be  evaluated  and  verified.  Along  with 
evaluating  these  assumptions,  there  is  still  considerable  work  remaining  to  be  done  to  go  from  stand  alone 
testing  to  a  fully  operational  USCG  capability.  Without  field  testing  on  a  larger  scale,  it  is  difficult  to  decide 
the  best  integration  solution  and  architecture.  The  architecture  described  above  proposes  interfaces  to  allow 
transmission  of  all  AIS  message  types;  however,  to  date  only  message  8’s  have  been  tested.  The  rest  of  the 
transmit  messages  types  will  need  to  be  tested  as  well. 

A  key  component  of  the  architecture  is  the  AIS  router.  Some  testing  has  been  done  on  commercial  options 
for  this  component,  but  only  on  a  limited  requirements  set.  Off-the-shelf  solutions  (i.e.  Gatehouse, 
Kongsberg)  should  really  be  fully  evaluated.  This  would  help  to  define  more  fully  the  USCG  requirements 
for  this  component  and  also  develop  acceptance  tests. 

This  proposed  architecture  also  needs  to  be  expanded  to  define  an  appropriate  regional-national  hierarchy 
and  interface  details  for  integration  with  external  agencies  such  as  the  US  ACE  remain  to  be  detailed. 

System  monitoring  is  also  a  vital  part  of  the  overall  system  performance.  A  working  group  to  investigate 
these  issues  should  be  formed  with  RDC  involvement. 

A  transition  plan  to  migrate  from  the  current  receive-only  system  to  a  full  transmit-receive  system  also 
needs  to  be  developed.  Some  NAIS  Interim  Receive  components  could  be  very  useful  in  the  final 
configuration,  especially  its  monitoring  and  analysis  capability,  and  should  be  evaluated.  The  working  group 
to  finalize  the  AIS  architecture  could  also  develop  the  transition  plan. 

With  this  type  of  capability,  spiral  development  is  highly  recommended.  Therefore,  the  working  group 
should  work  closely  with  RDC  for  the  implementation  and  testing  of  the  architecture  recommendations  as 
they  are  developed. 
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APPENDIX  A  AIS  TRANSMIT  PROJECT  BACKGROUND 
A.l  Background  on  AIS 

The  Automatic  Identification  System  (AIS)  is  an  autonomous  and  continuous  broadcast  system  that 
exchanges  maritime  safety/security  information  between  participating  vessels  and  shore  stations.  In  addition 
to  providing  a  means  for  maritime  administrations  to  effectively  track  the  movement  of  vessels  in  coastal 
and  inland  waters,  AIS  can  be  a  means  to  transmit  information  to  ships  in  port  or  underway  that  contributes 
to  safety-of-navigation  and  protection  of  the  environment.  This  includes  meteorological  and  hydrographic 
data,  carriage  of  dangerous  cargos,  safety  and  security  zones,  status  of  locks  and  Aids  to  Navigation 
(AtoNs),  and  other  port/waterway  safety  information. 

While  AIS  is  a  highly  effective  means  of  providing  information  to  a  United  States  Coast  Guard  (USCG) 
Sector  Command  Center  or  Vessel  Traffic  Service  (VTS)  Center  about  vessel  position  and  identification,  it 
can  also  be  used  as  a  tool  for  communication  by  utilizing  the  transmit  capability  which  includes  both  (1) 
broadcasts  to  all  users  within  range  and  (2)  addressed  messages  to  specific  users.  Since  2007,  USCG 
Research  and  Development  Center  (RDC)  has  been  working  to  establish  an  AIS  Transmit  capability  by 
identifying  requirements,  developing  processes  and  procedures,  and  testing  these  processes  and  procedures 
in  various  AIS  transmit  test  beds. 

A.2  Background  on  AIS  Transmit  Project 

The  two  primary  goals  of  the  USCG  AIS  Transmit  initiative  are  (1)  to  reduce  voice  communications,  and 
(2)  to  improve  navigation  safety  and  efficiency.  This  can  be  best  achieved  by  meeting  the  following 
objectives: 

•  Identify  and  prioritize  the  types  of  information  that  should  be  broadcast  using  AIS  binary  messages 
(now  referred  to  as  Application  Specific  Messages  (ASMs)):  information  that  is  available,  important 
to  the  mariner,  and  provided  to  the  mariner  in  a  timely  fashion  and  in  a  useable  format. 

•  Develop  recommendations  for  transmission  architecture  and  shipboard  display  standards. 

•  Obtain  data  to  support  the  goal  of  reduced  voice  communications  and  improved  navigation. 

To  meet  these  objectives,  the  USCG  VTS  Program  Office  initiated  the  RDC  AIS  Transmit  Project.  There 
were  three  main  tasks  to  this  project: 

1 .  Determine  functional  requirements.  The  goal  is  to  establish  what  the  AIS  capability  within  a  VTS 
should  be.  This  involves  identifying  and  gathering  information  from  various  A  IS/ VTS  stakeholders. 
This  is  an  iterative  process  throughout  the  project. 

2.  Establish  test  beds.  The  goal  is  to  test  concepts  and  ideas,  draft  standards,  and  validate  requirements 
prior  to  USCG  implementation  by  establishing  test  beds  in  existing  VTS  areas  and  encouraging 
active  participation  by  maritime  stakeholders. 

3.  Establish  a  Working  Group  within  the  Radio  Technical  Commission  for  Maritime  Services 
(RTCM).  The  purpose  of  the  Working  Group  is  to  review  current  VTS  AIS  capability  in  United 
States  (U.S.)  waters  and  recommend  “consolidated”  ASMs  for  regional  and  international 
implementation  and  to  identify  needed  changes  in  AIS  equipment  to  support  new  capabilities. 
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The  first  task  started  with  conducting  a  USCG  Requirements  Study  in  2008  [13]  that  clearly  showed  there  is 
a  need  and  a  desire  to  have  more  information  flow  from  the  VTS  to  the  mariners  as  data  rather  than  voice. 
There  was  also  a  clear  need  for  flexibility  in  the  information  delivery,  or  more  accurately,  the  ability  to  send 
the  data  that  is  needed,  to  the  people  who  want  it,  based  on  area  of  operation.  A  review  of  the  existing 
message  types  defined  in  International  Maritime  Organization  (IMO)  Safety  of  Navigation  Circular 
(SN/Circ.)  236  [14]  showed  that  they  would  not  be  useable  to  meet  the  information  transfer  needs  of  the 
maritime  community. 

These  conclusions  drove  design  considerations  for  the  development  and  testing  of  ASMs.  Phase  I  of  the 
project  focused  on  developing  and  testing  an  Environmental  Message  (EM)  ASM  to  transmit  environmental 
data  (tides,  currents,  etc.).  Phase  II  added  a  Geographic  Notice  (GN)  ASM  as  well  as  support  for 
demonstrations  in  Stellwagen  Bank  and  the  Columbia  River.  Phase  III  added  a  Waterways  Management 
(WM)  ASM  and  telecommands  (used  to  send  commands  directly  to  the  AIS  radio  onboard  ships). 

A.3  Test  Beds 

The  AIS  Transmit  project’s  primary  test  bed  is  located  in  Tampa,  FL.  The  project  also  expanded  to  include 
demonstrations  and  trials  in  the  Stellwagen  Bank,  MA,  Louisville,  KY  and  the  Columbia  River,  OR.  This 
work  has  been  reported  on  previously  in  [15-19]  but  is  summarized  in  the  sub-sections  below. 

A.3.1  Tampa  Bay,  FL 

The  Tampa  VTS  test  bed  was  installed  and  commenced  operation  in  September  2008;  the  site  selection 
process  and  installation  plan  are  documented  in  [20,  21].  The  system  diagram  (Figure  )  shows  the  processes 
(colored  blocks)  and  the  locations  where  they  are  running  (colored  clouds).  The  Fetcher/Formatter  (FF), 
Queue  Manager  (QM)  and  ARI  are  software  programs  running  on  a  computer  at  RDC  and  monitored  by 
Alion.  The  ASMs  are  sent  to  the  AIS  base  station  in  Largo,  FL  that  is  shared  with  the  VTS  operations 
system  (Norcontrol™  software  by  Kongsberg).  The  Nationwide  AIS  (NAIS)  receiver  at  Palmetto  is  used  as 
the  monitor  site  and  to  calculate  VHF  Data  Link  (VDL)  loading  using  Internet  Protocol  to  Communication 
Port  Conversion  Software,  IP2COMM,  (both  AIS  User  and  IP2COMM  are  also  running  on  the  QM 
computer).  Figure  shows  the  locations  of  the  base  station  (upper  left)  and  the  receiver  (lower  right)  relative 
to  Tampa  Bay.  Alion  and  VTS  personnel  are  monitoring  the  overall  system  performance  to  ensure  that  the 
data  is  getting  to  the  users.  Transview  (see  Figure  A-3),  ASM  Decoder  (see  Figure  A-4),  and  ARINC’s 
PilotMate™  software  are  used  both  at  RDC  and  the  VTS  to  monitor  operations.  Transview  in  conjunction 
with  VTS  Info  Manager  is  used  at  the  VTS  to  create  Geographic  Notice  messages. 
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Figure  A-l .  Current  state  of  VTS  Tampa  test  bed. 

(Grey  boxes  are  computers,  blue  boxes  represent  government  software,  databases,  or  equipment,  green 
boxes  are  Alion-developed  software,  and  orange  boxes  are  COTS  software  and  equipment.) 


Stakeholder  Feedback: 


•  The  Tampa  Bay  Pilots  and  VTS  (USCG  and  Port  Authority)  have  been  very  supportive  partners.  The 
test  bed  personnel  are  able  to  create  and  deliver  binary  message,  which  mariners  can  use  aboard  ship. 
This  information  provides  the  pilots  with  better  situational  awareness  of  met/hydro  conditions  in  the 
port  area  and  has  been  used  for  decision  support  (go/no-go  decisions). 

•  Physical  Oceanographic  Real-Time  System  (PORTS)  data  is  sent  using  the  ASM.  Pilots  preferred 
receiving  the  PORTS  data  through  the  AIS  broadcast  vs.  phone  or  Internet. 

•  The  Tampa  Pilots  also  preferred  the  text  display  of  the  data  to  a  graphical  display  on  their  Portable 
Pilot  Units  (PPUs). 

The  Tampa  test  bed  has  been  the  primary  test  site  to  evaluate  processes  and  performance  for  future 
implementation  at  all  Coast  Guard  VTS  sites.  The  testing  done  in  Tampa  has  enabled  an  understanding  of 
the  transmit  process  and  driven  the  development  of  the  proposed  transmit  architecture. 
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Figure  A-2.  Tampa  transmitter  and  receiver  sites. 
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Figure  A-3.  Sample  transview  (TV32)  display.  Change  above  to  geographic  notice. 
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Figure  A-4.  AIS  ASM  message  decoder  GUI. 


A.3.2  Stellwagen  Bank 

The  Stellwagen  Bank  demonstration  has  been  a  joint  effort  between  the  RDC  and  National  Oceanic  and 
Atmospheric  Administration  (NOAA)  National  Marine  Sanctuary  (NMS)(with  University  of  New 
Hampshire  (UNH)  and  Cornell  University  support).  The  location  of  this  test  bed  is  shown  in  Figure  A-5. 

The  goal  of  this  effort  is  to  broadcast  via  AIS  an  indication  of  the  presence  or  absence  of  right  whales  in  the 
vicinity  of  the  10  acoustic  monitoring  buoys  so  that  ships  can  slow  down  if  there  are  whales  in  the  area.  An 
overview  of  the  demonstration  set-up  is  shown  in  Figure  A-6.  The  AIS  broadcast  portion  of  the 
demonstration  commenced  operation  in  September  2008.  The  user  equipment  side  (NMS/UNH 
responsibility)  started  operation  in  earnest  with  an  iPad  application  (WhaleAlert)  in  2012.  NOAA  NMS  is 
the  overall  lead  for  this  effort.  Cornell  is  responsible  for  the  operation  of  the  acoustic  buoys.  They  receive 
the  acoustic  signature  data  from  the  buoys  via  an  Iridium  satellite  link  and  process  it  at  Cornell  to  determine 
if  right  whales  are  present  or  not.  This  information  goes  into  their  database  where  it  can  be  accessed  and 
viewed  over  the  Internet.  UNH  provides  software  support  and  wrote  the  code  that  retrieves  the  right  whale 
data  from  Cornell’s  database  and  provides  Geographic  Notices  to  the  Right  Whale  Queue  Manager  (this  is 
the  equivalent  of  the  Fetcher/Formatter  used  for  Tampa). 

The  FF  and  QM  are  currently  being  run  at  Cornell  and  monitored  by  UNH  (both  under  contract  to  NOAA). 
The  ARI  software  is  running  on  a  computer  at  Provincetown  and  provides  the  interface  to  the  AIS  AtoN 
transmitter  (this  was  substituted  for  the  original  base  station  in  Jan  2011).  The  NAIS  receivers  in  the  Boston 
area  are  used  as  monitor  sites.  Alion  and  UNH  are  monitoring  the  overall  system  performance  to  ensure  that 
the  data  is  getting  to  the  users. 
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Figure  A-5.  Stellwagen  Bank  demonstration  area. 

(Red  circles  indicate  whales  present;  green  circles  indicate  no  whales  detected.) 
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Figure  A-6.  Stellwagen  Bank  demonstration  architecture. 
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A.3.3  Columbia  River 

The  Columbia  River  Demonstration  has  been  a  joint  effort  between  the  RDC  and  the  Columbia  River  Pilots 
(COLRIP).  A  system  diagram  is  shown  in  Figure  A-7.  The  AIS  base  stations  (Green  Mountain  and 
Meglar  Mountain)  are  operated/monitored  for  the  COLRIP  by  the  Department  of  Transportation, 
Volpe  Center.  The  two  base  stations  are  operated  in  repeater  mode  so  that  all  traffic  received  is 
retransmitted.  Originally,  the  FF,  QM  and  ARI  were  running  on  a  computer  at  RDC  and  monitored  by 
Alion.  The  Volpe  Center  has  since  taken  over  the  AIS  transmit  operations  in  the  Columbia  River  (as  of 
Aug  2010)  as  part  of  their  contracted  support  to  the  COLRIP.  To  enable  this  transition,  the  FF,  QM,  and 
ARI  processes  were  moved  to  the  COLRIP  office  and  are  now  monitored  by  Volpe  along  with  the 
Transview  (TV32)  installation  that  is  there  now.  COLRIP  and  Volpe  are  responsible  for  monitoring 
system  performance  and  VDL  loading  using  data  feeds  from  the  two  transmitter  sites.  RDC  conducts 
monitoring  on  an  ad  hoc  basis  using  the  NAIS  receiver  at  Cape  Disappointment.  TV32  and  ASM  Decoder 
software  are  used  at  RDC  to  monitor  operations.  A  chart  showing  relative  positions  of  the 
transmitters/receiver  is  shown  in  Figure  A-8. 
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Figure  A-7.  Columbia  River  demonstration  system  diagram. 
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Figure  A-8.  Columbia  River  demonstration  diagram  showing  transmitter  locations. 

Colombia  River  Results/stakeholder  feedback: 

•  The  Columbia  River  Pilots  actively  use  the  environmental  data  as  part  of  their  operations. 

•  They  use  TV32  as  their  Personal  Pilot  Units  and  like  the  geographically  tied  text  display. 

•  The  test  bed  with  two  transmitters  in  a  repeater  mode  provided  RDC  with  some  valuable  experience 
in  repeater  operation  and  VDL  impacts.  This  is  documented  in  [9], 

A.3.4  Louisville,  KY 

VTC  Louisville  is  a  unique  Vessel  Traffic  Center  (VTC)  with  non-traditional  VTC  operational 
requirements.  VTC  Watchstanders  are  only  required  to  "stand  up"  when  the  Ohio  River  crests  above  13  feet. 
Due  to  the  infrequency  of  this  event,  typical  VTC  sensors  and  hardware  systems  are  not  installed.  Operators 
rely  primarily  on  a  network  of  five  cameras  and  a  standard  radio  system.  To  aid  watchstanders  during 
operational  events  and  to  increase  everyday  maritime  domain  awareness  in  the  VTC  Area  of  Responsibility 
(AOR),  VTC  Louisville  recently  added  AIS  capability. 

A  test  bed  was  established  in  Louisville  in  201 1  (see  Figure  A-9)  for  multiple  reasons.  First,  Louisville 
would  be  the  first  test  bed  to  be  established  inland,  away  from  a  major  port.  Second,  it  had  limited  line  of 
sight  VHF  signal  paths  due  to  winding  rivers,  land  mass  obstructions  and  heavy  foliage,  conditions  not 
encountered  in  a  typical  coastal  port.  Third,  it  was  the  first  test  bed  where  PORTS  data  is  not  available.  And 
finally,  it  was  a  VTS  that  had  a  lock  in  the  AOR.  The  goals  for  this  test  bed  were: 

•  Develop  and  test  new  sources  of  environmental  data  for  transmission  such  as  river  current  sensors 
and  river  gauge  sensors. 

•  Test  the  usage  of  the  WM  ASMs  and  assess  their  usefulness. 
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•  Develop  and  test  the  automatic  generation  of  WM  ASMs  from  US  ACE  data  sources  (vessels 
awaiting  lockage). 

•  Test  the  usage  of  the  Synthetic/VTS  Target  ASM. 

•  Test  the  usage  of  Telecommands  and  assess  their  usefulness. 

•  Test  AIS  Transmit  effectiveness  for  inland  waterways  environments. 

•  Assess  the  benefits  of  Enhanced  AIS  for  inland  waterways  vessel  traffic  management. 

This  test  bed  was  also  the  first  to  be  set  up  using  the  new  transmit  architecture  and  processes.  Although  this 
provided  a  good  test  bed  for  developing  the  new  architecture  software,  of  the  7  goals  listed,  only  some  were 
met  during  the  Phase  I  test.  Specifically,  goals  1  and  3  were  met;  message  encoders  were  developed  to  pull 
data  from  USACE  (flow  and  gauge),  from  National  Weather  Service  (NWS)  (airport  weather),  and  from 
storm  warning  database.  Vessels  queue  information  from  three  locks  (McAlpine,  Cannelton,  and  Markland) 
was  also  transmitted  (see  Figure  A- 10).  Goal  number  2  could  not  be  met  as  the  user  software  was  never 
completed  by  Channel  ECDIS  and  Course  Trajectory  (CEACT)  navigation  software,  so  although  messages 
were  being  transmitted,  they  were  not  decoded  and  displayed.  CEACT  is  navigation  software  used  by  some 
vessels  on  the  Ohio  River.  Goals  4  and  5  were  not  done  due  to  insufficient  time  and  lack  of  user  software 
support.  Goals  6  and  7  could  not  be  fully  assessed  due  to  the  lack  of  user  software. 
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Figure  A-9.  Louisville  test  bed  architecture. 
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Figure  A- 10.  Louisville  test  bed  TV32  display  showing  environmental  data,  lock  queue  information,  and  vessels. 
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In  order  to  complete  the  assessment  processes,  the  decision  was  made  to  conduct  a  Phase  II  test  at 
Louisville.  The  goals  of  the  second  phase  are  to: 

•  Fully  test  the  Waterways  Management  Message  and  assess  its  usefulness  from  the  mariner’s  point  of 
view. 

•  Assess  the  Integration/Management  of  AIS  AtoN  into  the  transmit  architecture. 

•  (Optional)  Test  the  Telecommands. 

The  start  of  the  Phase  2  test  bed  is  contingent  upon  several  work  items: 

•  Final  approval  of  AIS  ASM  messages  and  their  incorporation  into  the  user  software.  Completed  in 
May/June  2013. 

•  Repair,  relocation  or  replacement  of  the  Acoustic  Doppler  Current  Profiler  at  Louisville  in  order  to 
provide  a  source  of  current  data.  This  is  in-progress  and  expected  to  be  complete  00 A  1  July  2013. 

•  Addition  of  a  weather  sensor  to  provide  local  wind  speeds.  Completed  -  weather  station  is  being 
placed  at  the  lock. 

•  USACE  must  restore  the  lock  queue  information  accessibility  (due  to  a  changeover  in  the  USACE 
systems,  the  data  source  previously  used  is  no  longer  available).  Completed  -  functionality  for  lock 
queue  is  now  available  through  the  new  system. 

•  Approval  of  a  new  Interim  Authority  To  Test  (IATT).  Approved  for  180-day  period  starting  July  1, 
2013. 

Since  the  work  items  have  been  completed  or  are  projected  to  be  complete,  the  Phase  2  test  is  scheduled  to 
start  on  1  July  2013. 
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